Migrate MockMvc Hamcrest assertions to AssertJ - #1120
Conversation
|
Thanks for the suggestion here @Ouweshs28 ; Over at Moderne we already have a recipe for this type of change, and I know it's quite a bit more involved as compared to the work done here: That brings us into a bit of a weird spot: I know the changes here are insufficient, and that might break trust with users of this recipe, or the larger Spring Boot 4 migration recipe which includes this change. That makes me somewhat hesitant to move forward with the current iteration of this recipe. Not quite sure what's the best way forward here. I've marked this as draft until we figure out a clear path. |
|
Thanks, that makes sense. I agree that an incomplete conversion should not be included in the broader Spring Boot 4 migration: inconsistent handling of common MockMvc patterns could undermine trust in the recipe. I suggest we treat this PR as a prototype and do not merge the current implementation as-is. If the Moderne recipe can serve as a suitable reference for an OSS implementation, I’m happy to rework this against an agreed behavior matrix and representative tests until it reaches an appropriate level of coverage. If that implementation cannot be ported or shared as a reference, I think closing this PR and leaving the issue open is preferable to shipping a knowingly incomplete migration. Would you be able to advise whether there is a portable reference implementation or set of supported before/after cases I could use for the next iteration? |
What's changed?
Adds a Spring Framework 6.2 migration recipe that converts chained MockMvc
andExpect(...)assertions to the AssertJ-based MockMvc API.The recipe wraps existing
MockMvc.perform(...)calls withMockMvcTesterand converts each expectation tomatches(...), preserving the original request builders and result matchers.What's your motivation?
Spring Framework 6.2 introduced AssertJ support for MockMvc. This recipe provides a safe migration path for existing Hamcrest-style assertion chains and is included in the Spring Framework 6.2 upgrade recipe.
Anything in particular you'd like reviewers to focus on?
The migration deliberately preserves existing request builders and
ResultMatcherinstances throughMockMvcTester.perform(...).matches(...).Have you considered any alternatives or workarounds?
A fuller conversion to fluent request construction and specialized AssertJ assertions would require mapping many request-builder and matcher variants. This first migration uses Spring's documented AssertJ bridge to preserve behavior safely.
andExpectAll(...)is intentionally left unchanged because its aggregate-failure semantics cannot be preserved by a chain of AssertJ assertions.Any additional context
The recipe includes positive coverage for chained
andExpect(...)calls and negative coverage forandExpectAll(...).Checklist